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SPADE: A Grammar Based Editor For Planning And Debugging Programs 


Mark. L. Miller and Ira P. Goldstein 


A grammar of plans is developed from a taxonomy of basic 
planning techniques. This grammar serves as the basis for the design of 
a new kind of interactive programming environment (SPADE), in which 
programs are generated by explicitly articulating planning decisions. 

e utility of this approach to program definition is that a record of 
these decisions, called the plan derivation, provides guidance for 
subsequent modification or debugging of the program. 

Moreover, this grammatical approach to planning allows the 

development of a taxonomy of bugs, as particular kinds of errors in 

applying the planning grammar. Following a linguistic analogy, five 

types of planning bugs are characterized: syntactic, semantic, 

pragmatic, circumlocutions, and slips of the tongue. The plan derivation 

can be accessed during subsequent debugging, to aid in diagnosing the 

underlying cause of erroneous code. Repair is accomplished via 

replanning, in which a substructure of the derivation is replaced. A 

debugging assistant for the SPADE environment (RAID) is designed based on 
this theory. 


The enterprise embodies Dijkstra's philosophy of programming in 
a structured fashion, but represents a more detailed study of planning 
and debugging techniques than has previously been attempted. 


This re Port describes research done at the Artificial Intelligence 
Laboratory of the Massachusetts Institute of Technology. It was supported in 
par by the National Science Foundation under grant C40708X, in part by the 
Advanced Research Projects Agency of the Department of Defense under Office of 
Naval Research contract N00014-75-C-0643, and in part by the Division for Study 
and Research in Education, Massachusetts Institute of Technology. 
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1. Introduction 


1.1. Background and Objectives 


Our goals in this report are: (1) to understand the processes by which a 
programmer, whether human or machine, moves from a declarative statement of a 

Z lTu \° 3 Pr ° CedUral statement of its solution; and (2) to discover methods 
by which these processes can be facilitated. We see programming as involving two 

P H? 1 ? 1 ® activitles: Planning and debugging. Most previous research has 

w A T activities in a " isolated fashion. This report presents a 
unified theory of planning and debugging, based on a linguistic analogy. 


The investigation includes the design of an interactive programming 
environment called SPADE. SPADE is an acronym for Structured Planning and 
ebugging Editor. This name emphasizes two themes: (1) our perspective on 

SDanrTA" 9 aS 3 process of plannin 9 and debugging; and (2) our expectation that 
SPADE-like systems will eventually help in achieving the structured programming 

movement s goals of program reliability, readability, extensibility, portability 
and so on. The objectives for the SPADE programming environment are that it 
serve, not only as a practical application of the theory, but also as an 
experimental crucible for testing claims of the theory. 1 


In other papers the authors elaborate other dimensions of this linguistic 
approach to problem solving. [Miller & Goldstein 1976a] provides an overview of 
our re search as a whole. [Goldstein & Miller 1976a] presents a long term 
research direction: applying the problem solving theory to the construction of a 
earning environment to teach elementary programming. In [Goldstein & 

er tfle authors des ign PATN, an automated problem solver. In [Miller & 

Goldstein 1976b] the authors consider the use of grammars in the analysis of 

elementary programming protocols. In [Miller & Goldstein 1976d] the authors take 
steps toward automating this analysis task by designing a system called PAZATN. 


1.2. Overview 


The basis for SPADE's design is a unified problem solving theory which 
incorporates a fundamental linguistic analogy. The theory rests on a taxonomy of 
basic planning techniques. Planning, according to the theory, proceeds by a 
sequence of design decisions, in which the programmer selects a plan type and 
en carries out the subgoals defined by the application of that plan type to the 
current problem situation. This decision process is modeled by a context free 


This analysis of planning leads to a taxonomy of program bugs as well. 
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that C <~far«: 1* 3 \ th60ry UnifUS planning and ^bugging is based on the fact 

o bugs are defined by tracing their origins to particular types of 

analoav US . eCiSi °" S aPPlying the planning grammar. Following a linguistic 

? " 9 bugs are characterized as: syntactic, semantic, 

pragmatic, circumlocutions, and slips of the tongue. 

-1 __ SyStem WlU provide an interpreter for context free grammar 

olanni h V Provide bo ^keeping facilities, maintaining a record of the 

Lnornt H d . eClaions made in the application of each rule. This data structure 
generated by the grammar is called the plan derivation. Programs are merely the 

terminal strings of such derivations. Hence, SPADE should encourage programmers 

imoiiri* 1 *! their P lannin 9 decisions, rather than merely leaving the plan 
implicit in the resulting code. 


. , Tbe derivat ion structure created during planning episodes can be accessed 

during subsequent debugging episodes to aid in diagnosing the underlying cause of 
malfunctioning code. Repair would then proceed via replanning, in which a 
substructure of the plan derivation is replaced. One result of this repair would 
be that the purely hierarchical derivation tree is replaced by a cAert of 
a ernat ve derivation trees. Diagnosis and repair techniques based on this 
eory are to be implemented in a debugging assistant called RAID (for RAtional 
Implementation of Debugging). RAID will be a component of the SPADE environment. 

wtom T ™ S < Paf ! er Presents the design for SPAD E- We plan to implement the 
system The implemented system will serve as the basis for a set of experiments 

exploring aspects of the theory, such as the relative effectiveness of 

alternative planning grammars. Examination of session transcripts coupled with 

systematic interviews of SPADE users will provide evidence for answering the 
following sorts of questions: a 


1. Do users find the planning grammars adequate; or are there 

planning decisions which simply cannot be made given the 
restrictions of the grammar? 


2. How much of the grammar would remain the same in moving from 

one application to another? We initially plan to implement the 

domain dependent portion of the grammar for the Logo elementary 

graphics programming domain. 2 Later we intend experimenting with 

planning grammars for different domains, to include: the 

"blocks world," a set theory world, and an elementary calculator 
world. 


3. Do the plan derivation structures generated by the grammar 
serve as useful documentation, aiding one programmer in 
understanding and modifying programs written by another? 
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4. How effective is the system as a pedagogical alternative for 
teaching programming and problem solving? Can its effectiveness 

be attributed to such factors as greater articulation of 
planning and debugging strategies? 4 


Th ® ansKBrs t0 theSB questions. In turn, will shed light upon a larger 
vatnnhi" by the 8nter ' ,ris, > : «oes computational linguistics provide a 

problem Solving? C °" CePtS ^ algorl . th " s for 88 " 8 fuctlng a theory of 


• . . Section two Presents our theory of planning. The third section 

roduces the SPADE system. Our theory of debugging, and its embodiment in 

limitation, !° P “ ° f SeCti °" S four and f * v e- We conclude by discussing 
notations, extensions, and applications to structured programming, automatic 
programming, and protocol analysis. 
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2. A Grammatical Theory of Planning 

. It would help a great deal if we had a general language 
specially designed for talking about Plans.... Such a language 
would, presumably, give us a convenient notation for such 
aspects as flexibility of Plans, the substitution of subplans, 
conditional and preparatory subplans, etc. For example, it does 
not particularly matter in what order Mrs. Jones chooses to run 
her errands when she gets to town. The ... subplans can be 
permuted in order, and so we say that this part of her Plan is 
flexible. But she cannot permute the order of these with the 
subplan for driving to town, or for driving home. That part of 
the plan is inflexible. Some subplans are executed solely for 
the purpose of creating the conditions under which another 
subplan is relevant. Such preparatory or mobilizing subplans 
cannot be freely moved about with respect to the other subplans 
that they anticipate. Another important dimension of freedom 
that should be analyzed is the interchangeability of subplans. 
Mrs. Jones can drive to town over a variety of equivalent 
routes. The variety is limited only by the condition that they 
terminate when one of her three alternative destinations is 
reached, since only then would the next part of her Plan become 
relevant. Given a satisfactory Plan and a statement of the 
flexibility and substitutability of its subplans, we should then 
be able to generate many alternative Plans that are also 
satisfactory. And we should like to have ways for deciding 
which combinations of Plans are most efficient.... 

[Miller et al. 1960] 


2.1. A Taxonomy of Plans 

Dlannlno H lve * syntax of P lans » we begin by formulating a taxonomy of 

techn i mi , ? u' 9Ur ® 1 presents a taxonomy of a variety of common planning 

examinJn hi 3rriVed at thls taxonomy Partly by introspection, partly by 

s^udiina tJI ? I 9 Pr ° tOCOls CMlller * Goldstein 1976b], and partly by 
1967 ^Qfini an ® lyses of Problem solving provided by Polya [1957, 1962, 1965, 

different i' < is inconplete: different domains would emphasize 

pianning techniques. Yet there is certainly a core set of planning 
techniques common to all domains*^ 


The initial division in the taxonomy is into planning by identification 

SiSrrrr and h ? 5, T° rmuiau °"' ^ fim ««•«<»* “«»«* those methods 

,! y id ' ntlfyi " 9 “ «* «»• "»lch is already known. The 

prov es guidelines for breaking the problem into pieces. The third 
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IDENTIFY 


PRIMITIVE 


PREVIOUSLY DEFINED PROCEDURE 


(-SET 


(-LINEAR- 


1—CONJUNCTION- 


PLAN - DECOMPOSE- 


(-SEQUENTIAL 


'DECOMPOSITION 


HNONLINEAR- 


(“COMPOSITION 


■REPETITION 


■ROUND 


(-RECURSION 


REFORMULATE—1 


■EQUIVALENCE- 


-REGROUP 


•GENERIC <-> EXPLICIT 


SIMPLIFY. 


SPECIALIZE 


’GENERALIZE 

-ANALOGY 


FIGURE 1 

TAXONOMY OF PLANNING CONCEPTS 
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* ec * niques tha ^ aUeffl l> t t0 reformulate the problem into a form more 
amenable to identification or decomposition. 

„ Bnro *u FOr | / ny ^ 0n5ain ’ there are P rimit ives and previously solved problems. 
Hence, the identification class breaks into these two sub-categories. Of course, 

there can be enormous subtlety in how a problem is recognized as an instance of a 

rr ..."I / SOlved case * Constructing a taxonomy does not resolve this issue. In 
[Goldstein* Miller 1976b] we introduce formal descriptions of the problem 
domain, and hence can address this issue more precisely. 

There are many decomposition techniques. The taxonomy of figure 1 cites 
only two: decomposition into conjunctive subgoals and decomposition into a 
single subgoal, repeated some number of times. Other decomposition techniques 
are appropriate for problems that can be decomposed into a disjunctive set of 
subgoals, or into a negation of some goal. Conjunction involves the critical 
question of whether each conjunct can be solved independently of the others, or 
whether there are interactions. Repetition divides into solution by simple 
iteration of a single subgoal or solution by full recursion. 


Reformulation is perhaps the subtlest of the planning categories. It 

includes finding an equivalent formulation of the problem which presumably is 

easier to solve or a critical simplification whose solution is a stepping stone 

o the solution of the original problem. Occasionally, one may even reformulate 

a problem into a stronger form: such as constructing an example when only an 
existence proof is required. 


How can we further explore this set of planning concepts? Our first step 

S «.K° 4 be , m ° re explicit about the Vision process involved in selecting planning 
methods from this taxonomy. 


2.2. A Planning Grammar 


We view planning as a process in which the problem solver selects the 
appropriate plan type and then carries out the subgoals defined by that plan 
applied to the current problem. 7 From this viewpoint, the planning taxonomy 
represents a decision tree of alternative plans. This decision process can be 
orma ized by a context free grammar. 8 A grammar is chosen to present these rules 
because It provides . siuplo sod coupact representation, useful for 
characterizing the hierarchical structure of planning. We would not argue that a 
context free grammar is the appropriate formalism for representing a complete 
theory of problem solving -- elsewhere we employ a more elaborate formalism. 

However, we believe that the grammar represents a useful abstraction of the 
decision points in the planning process. 
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The top level rule in the problem solving grammar is: 


PI: SOLVE 


-> PLAN + [DEBUG] 9 


The nonterminal SOLVE is formally analogous to the nonterminal SENTENCE in a 
nguistic grammar for parsing or generating sentences. PI states that planning 
is first used to generate a plan, with subsequent debugging then being required 

!® Pl “* *'"• S ° lutl0n - 0f c °" r ^ «i. plan may be entirely correct. For this 
DEBUG ls in brack ett. Indicating that it is an optional constituent. We 
shall have more to say about debugging in a later section. 

The planning taxonomy characterizes the planning process as involving 
three mutually exclusive plan categories: identification, decomposition, and 

7/tZTlT ’ ln Planning ’ the P roblera so lver must choose among these 

alternatives. We represent this by the disjunctive rule P2. 


P2: PLAN 


-> IDENTIFY | DECOMPOSE | REFORMULATE 


Tri _ ”°* let US conslder the details of each of these planning categories. 

nrnhi ifiC T^° n , COnSiSted ° f USln9 a primitive or using a previously solved 
problem. This is described by P3. 


P3: IDENTIFY 


-> PRIMITIVE | DEFINED 


The first alternative leads to the use of primitives from the particular problem 
domain being investigated. 


The planning theory is modular, and independent of the application 
domain. But it is obviously critical to illustrate its applicability by concrete 
examp es. In this report, we use the Logo elementary graphics programming domain 
as our source of examples. The task in this domain is to draw pictures with a 
cursor called the "turtle" by means of programs that move the cursor on the 
screen. Figure 2 illustrates the grammar rules for the primitives of this 

omain Figure 3 illustrates a typical goal undertaken by beginning programmers, 
a "wxshingwell picture." 


The second identification alternative, DEFINED, involves retrieving a 
solution from the library of previously defined solutions and inserting it into 
the current solution. These two steps are captured by the rule P4. 

P4: DEFINED -> USE-CODE & GET-FILE 10 

We now turn to the second major planning category, decomposition. Two 
important decomposition techniques are conjunctive plans, in which the problem is 
sub-divided into independent parts, and repetition plans, in which the problem is 
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Figure 2. Grammar Rules for logo Primitive 


LI. 

PRIMITIVE 

-> 

L2. 

VECTOR 

-> 

L3. 

ROTATION 

-> 

L4. 

PENSTATE 

-> 


VECTOR | ROTATION | PENSTATE 
FORWARD|BACK + "number" 

LEFT|RIGHT + "number" 

PENUP | PENDOWN 
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characterized in terms of a sub-problem repeated some number of times 


P5: DECOMPOSE 


-> CONJUNCTION | REPETITION 


Dlans« ln ? 1Ud6 ° th ® r Pl3nS f0r decora P° sin g problems, such as disjunctive 
plans, this rule would be extended by adding additional options. 

nonlinpap^ 6 shows con Junction as splitting into two cases: linear and 

nonlinear. The linear case is intended to represent the situation wherein the 

nrnh? S0lV6d entirely independently. The solution to the original 

P blem then becomes simply sequencing the solutions to the subgoals- or in 

rZn C ^? S ' executing then in any order > i- e the independence extends even to’the 
composition process. Solving for the roots of a factored polynomial is linear 

(each root can be solved for independently) and the composition is set structured 

( e order of the solution does not matter). Solving for the sub-pictures of the 

h :r 9W :“ Sh0Wn earlier is inde Pendent, but to obtain the desired relations 
etween the parts, some specific sequence must be established. Rule P6 defines 
the two cases for conjunction: 


P6: CONJUNCTION 


-> LINEAR | NONLINEAR 


Rule P7 specifies the two alternatives for a linear solution: 


P7: LINEAR 


-> SET | SEQ 


. < P7 is incomplete: The composition of independently solved subgoals might 

be in parallel or via some interrupt control structure. A goal of our research 

is to develop the depth and breadth of the taxonomy and its associated procedural 
forms so as to include such constructs. 

„ . A ”" uentia l Pi*" consists of a sequence of actions, each consisting of a 

main step followed by an optional interface; these are preceded and followed by 
optional setup and cleanup steps. J 

P8: SEQ *> [SETUP] + <MAINSTEP + [INTERFACE]>* + [CLEANUP] 

The essence of a sequential plan is that the solutions to the main steps can be 
designed independently of each other. 

' A set plan is simpler: the independence of the composition implies that 
no setup or cleanup steps are necessary. 


P9: SET 


-> <STEP> 


For the programming domain, a setup, main step, interface, or cleanup 
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consists of either the addition of a line of code 
SOLVE. 


or a recursive application of 


P10: SETUP 
PI1: MAINSTEP 
P12: INTERFACE 
P13: CLEANUP 
P14: STEP 


-> STEP 
-> STEP 
-> STEP 
-> STEP 

-> ADD | SOLVE 


The grammar now admits potentially infinite recursion. What is not 
ormaiized by the context free grammar is the fact that SOLVE is always attempted 
ith respect to some specific problem and in a definite context. Successful 
planning involves solving successively simpler problems until a direct solution 
in terms of the answer library is possible. The semantic and pragmatic 
components, formalized in [Goldstein & Miller 1976b], would constrain the 
potentially infinite recursion allowed by the grammar. 


Similarly, the grammar does not capture the distinction between a setup 
main step, and cleanup: they are all simply steps. There is, however, a 
semantic distinction. For example, the distinction between a main step and a 
setup depends on whether the code is designed to directly accomplish some subgoal 
a main step; or to establish some prerequisite for accomplishing some subgoal 
-- a setup. For example, in the Logo graphics domain, main steps generally 
involve drawing a visible part of the picture while setup steps have the goal of 
invisibly modifying the position or heading of the turtle between adjacent main 
steps. The Mycroft program [Goldstein 1974] included a program annotator that 
made such distinctions by comparing the picture drawn by the code with a 
predicate logic description of the intended picture." 


P15 states that repetition plans can be accomplished either by simple 
loops or by full recursion. (The latter is not elaborated here.) 

P15: REPETITION -> ROUND | RECURSION 


A round plan is the simple looping case, which can be accomplished either by 

iteration or by tail-recursion. (Tail-recursion is the restricted case wherein 

the recursion is constrained to be the last line of the program. It is 

computationally equivalent to a simple loop structure.) The following rule 
captures this: 


P16: ROUND -> ITER-PLAN | TAIL-RECUR 

Figure 4 illustrates a triangle being accomplished by three different 
Logo programs. These correspond to the use of a sequential plan, a recursive 
round plan and an iterative round plan. The annotations in parentheses, stating 
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Figure 4. Accomplishing A TriannU 


(Sequential Plan) 


TO TR1-SEQ 


FO 100 


In Step—(accomplish side one)- 


RT 120 Interface Step—(prepare heading for side two)- 


FO 100 Main Step-(accomplish side two)——_ 

RT 120 —Interface Step-(prepare heading for side three)-" 

F0 100 Main Step-(accomplish side three)_ 

RT 120 —Cleanup Step-(accomplish heading transparency)- 


FD 100 


Sequential 

Plan 


END 


(Tail Recursive Plan) 


TO TRI-REC 


• ( no st °P step: does not halt) ! 


FO 100 -Main Step-(accomplish side n)_I j 

RT 120 -Interface Step-(prep. heading side n+1)—I ~1 


TRI-REC 


END 


•Recursion Step- 


•— Tall 
J Recursive 
Plan 


(Iterative Plan) 


TO TRI-ITER 


REPEAT 3 


■Repeat Step 



FD 100 —Main Step-(accomplish side n)- 


•-Iterative 


RT 120 


Interface Step-(prep. heading side n+1)- 


♦-Seq Pla 


j p ' 


END 
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what the planning step is intended to accomplish, are semantic descriptions not 

nt n :r: d . y th ? grammar ' The 9 raoaar must be supplemented by semantic 
interpretation rules to allow for such analysis. 

Tail recursion may be represented as a sequential plan plus recursion and 
stop steps. Iteration is similar. 


> "repeat step" + SEQ 

> STOP-STEP + SEQ + REC-STEP 

> "recursive program call" 

> "stop program call" 

Reformulation, the third major planning category, should be briefly 

mentioned. Figure 5 provides a simple example of reformulation by regrouping the 

parts: a wishingwell, originally decomposed into a roof, a pole and a well, is 

later viewed as decomposable into a tree and a well. Reformulation techniques 

depend intimately on the problem description. Hence, we do not consider them 

further in this report. The subset of the planning grammar employed here is 
summarized in figure 6. 


P17: ITER-PLAN 
P18: TAIL-REC 
P19: REC-STEP 
P20: STOP-STEP 
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Figure 5 

REFORMULATING THE WISHINGWELL IN TERMS OF A TREE 



Since SPADE-0 has no problem description, it may not always 

BE APPARENT WHEN A REFORMULATION HAS OCCURRED, SOMETIMES IT 
WLLL BE APPARENT, THOUGH, FROM THE DIALOGUE, FOR EXAMPLE: 

la. What are your subgoals? 

lb, Roof, pole, well, 

2a, What would you like to do? 

2b, Redo choice 1, 

3a, Choice 1 undone. 

What are your subgoals? 

3b, Tree, well. 

4a. Rule for tree is: solve -* 


«+ ft 
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Figure 6. G2: A Grammar of Plans 


PI: 

SOLVE 

-> PLAN + [DEBUG] 

P2: 

PLAN 

-> IDENTIFY | DECOMPOSE | REFORMULATE 

P3: 

IDENTIFY 

-> PRIMITIVE | DEFINED 

P4: 

DEFINED 

-> USE-CODE & GET-FTLE 

P5: 

DECOMPOSE 

-> CONJUNCTION | REPETITION 

P6: 

CONJUNCTION 

-> LINEAR | NONLINEAR 

P7: 

LINEAR 

-> SET | SEQ 

P8: 

SEQ 

-> [SETUP] + <MAINSTEP + [INTERFACE]^ 

P9: 

SET 

-> <STEP>* 

P10: 

SETUP 

-> STEP 

Pll: 

MAINSTEP 

-> STEP 

P12: 

INTERFACE 

-> STEP 

P13: 

CLEANUP 

-> STEP 

P14: 

STEP 

-> ADD | SOLVE 

P15: 

REPETITION 

-> ROUND | RECURSION 

P16: 

ROUND 

-> ITER-PLAN | TAIL-RECUR 

P17: 

ITER-PLAN 

-> "repeat step" + SEQ 

P18: 

TAIL-RECUR 

-> STOP-STEP + SEQ + REC-STEP 

P19: 

REC-STEP 

-> "recursive program call" 

P20: 

STOP-STEP 

-> "stop program call" 


+ [CLEANUP] 
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3. The SPADE Editor 

How can we validate a particular grammar? How can we judge whether the 

C . aptUr ' es at sorae level of abstraction the set of planning decisions 
involved in solving problems for some domain? One traditional methodology for AI 

s to develop an automated problem solving system. The grammar, however, is 
nsufficient for this. Semantics and pragmatics are required to make our theory 
eterministic. (We develop this in [Goldstein & Miller 1976b].) 


But another methodology is possible. This involves incorporating the 
grammar into an intelligent editing system to augment the capabilities of the 
human problem solver. The critical question is whether such an intelligent 
support system successfully aids the user. In this section we design SPADE, an 
e tor for defining programs that incorporates our planning gr amma r 



The name Structured Planning and Debugging Editor emphasizes the link 
between the problem solving theory being evolved here and the structured 
programming movement. Dahl, Dijkstra, and Hoare [1972] properly argue for 
programs that reflect coherently structured problem solving. But they do not 
develop a theory of planning in any great detail. Our effort in this direction, 

e n?^ re ’ naturally ^PPieroents the examination of programming style initiated 
by Dijkstra and colleagues. 


Figures 7a and b illustrate an interaction with SPADE-0, our proposed 

grammar based editor. The user is interested in defining a Logo program for 

drawing the wishingwell shown earlier. In the SPADE environment, this is done by 

applying the planning grammar in generative mode. The user begins by specifying 

w e er the plan is to be an identification, decomposition or reformulation. The 

editor keeps track of the pending subgoals, allowing the user to move from one 
goal to another. 

Consider lines 6a and b of the SPADE-0 scenario. 

6a. Do you wish to include the optional constituent CLEANUP? 

6b. >LATER 

These lines illustrate the user suspending one subgoal, without completing it in 
order to pursue another. Although SPADE'S default is to suggest subgoals in -top 
down order, the system will offer the user the freedom to deviate from this 
e ault, pursuing the set of required goals in any other order. The decision as 
to whether a CLEANUP step is needed in the sequential plan is part of the 
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Figure 7a. SPADE-0 Scenario (part a) 


u3er ., ""'‘"AT" 0/ SM " ‘ S ,itt,e " lore «■* « fooMeeser /or t/,e 

ubgoals. It is currently being implemented by assigning an interoretive 
procedure to each grammatical primitive. interpretive 


la. What is the name of your top level procedure? 

lb. >WW 


2a. Rule for WW is: SOLVE -> PLAN + [DEBUG]. 

Rule for WW-1 is: PLAN -> IDENTIFY | DECOMPOSE | REFORMULATE 
What now? 

2b. DECOMPOSE 


3a. Rule for WW-4 is: LINEAR -> SEQUENTIAL | SET. 

What now? 

3b. SEQUENTIAL 

4a. Rule for WW-5 is: SEQ -> [SETUP] + <MAIN + [INTERFACE])* + [CLEANUP] 

Do you wish to include the optional constituent SETUP? 

4b. >No 


5a. How many occurrences of <MAIN + [INTERFACE]) do you want? 

5b. >3 

9 

6a. Do you wish to include the optional constituent CLEANUP? 

6b. >LATER 

LATER is a command understood by SPADE. It means that the user wants to 
erminate this path, but that it must be recommenced later. SPADE keeps track of 
onjunctive goals, reminding the user of the pending goal list if asked. Here it 
records the information required to return to, and eventually complete, the 
application of the SEQ rule. It can then go on to other goals. 
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7b* >POLE Pendin9 9 ° alS are and WELL. What NOW? 

SPADE applies the SOLVE rule recursively. 

8a. Rule for POLE is: SOLVE -> PLAN + [DEBUG] 

Rule for POLE-1 is: IDENTIFY | DECOMPOSE | REFORMULATE. 

What now? 

8b. IDENTIFY 

9a. Rule for POLE-2 is: IDENTIFY -> PRIMITIVE | DEFINED. 

What now? 

9b. PRIMITIVE 

10a. Rule for POLE-3 is: PRIMITIVE -> VECTOR | ROTATION | PENSTATE 
What now? 

10b. >VECTOR 


>FORWARD 100 

11a. POLE completed. Pending goals are: ROOF, WELL, and WW-17 (CLEANUP of 
WW). What now? 

lib. >WELL 


12a. Rule for WELL-1 is: PLAN -> IDENTIFY | DECOMPOSE | REFORMULATE. 

What now? 

12b. ^DECOMPOSE 

Here we have substituted a grammar which contains rules for conjunction but not 
repetition. This allows us to illustrate the manner in which SPADE avoids 
interrogating the user when no actual decision is required. 

13a. Rule for WELL-4 is: DECOMPOSE -> CONJUNCTION. 

(Forced.) 

Rule for WELL-5 is: CONJUNCTION -> LINEAR | NONLINEAR 
What now? 
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cI^miT h f0r J h8 s “ perprocedur8 - <*»* aoal of dociding Mother to iuciuie the 
CLEANUP should not be confused with the goal of designing the CLEANUP once the 

or has been established.) Some users night prefer to defer this 
decision until the main steps have been further elaborated. SPADE should be able 
to accomodate the alternative solution order. 

typeout commencing at line 13a illustrates another feature of SPADE- 
o. (A similar sequence is shown at 2a.) 

13a. Rule for WELL-4 is: DECOMPOSE -> CONJUNCTION. 

(Forced.) 

Rule for WELL-5 is: CONJUNCTION -> LINEAR | NONLINEAR 
What now? 

Since the grammar is interpreted (rather than being "programmed in"), it is easy 

to try out alternative grammars. Suppose, as is shown here, we employ a 

simplified grammar in which the REPETITION rules have been eliminated. (This 

might be useful in tutoring a novice for example.) Then no decision is actually 

required in applying the DECOMPOSITION rule. SPADE should notice this, and not 
interrogate the user in such cases. 

Figure 8 illustrates one possible derivation tree for WISHINGWELL as 

d ®^ ne K d USi " 9 SPADE "°* The util i*y of this record of the user's design decisions 
will become clearer when additional features of SPADE-0 are presented in the 
section on RAID. 


The implementation of SPADE-0 (which is now in progress) will not be 
difficult. It is simply a bookkeeeping system for applying the planning grammar 
in generative mode to build a solution. The basic implementation technique is to 
provide an interpretive procedure for each grammatical operator (such as "I"). 
Additional features can be implemented by assigning specialist procedures to non¬ 
terminals of the grammar, as will be done for the debugging assistance 
illustrated later. 


3.2. Towards SPADE-1, and Bevond 

There is an upper bound on the utility of SPADE-0 which cannot be 
overcome by more careful human engineering. This is due to the fact that SPADE-0 
does not have access to a description of the problem being solved. When 
application of the grammar rules results in a recursive application of SOLVE 
SPADE-0 has no notion of the relationship of the subproblem to the top level 
, T ° 0Verc0Ine this fundamental limitation, we intend to design and implement 
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SPADE l win h 9 , h ° WS 3 hypothetical interaction with SPADE-1. In many respects, 
SPADE-1 will be similar to SPADE-0. It still is governed by a set of context fr^ 

® m ? r PUl ® s ’ and stiU Provides bookkeeping facilities for suspending and 

description' o^th' "Tr" f"''* that the user “PPly ■ formal 

"Tr problem. (A library of standard problem descriptions is 

hOTOvtt in„l S t e “ t, 1 " 9 H bl0CkS) ' The “ 5ar need not PP-Pfy request: 

however, without the problem description, SPADE-1 can help only as much as SPADE- 

assistant Tt- Pr ° b 1 1 r deScription ' SPADE -i w °nld be able to provide additional 

ih, n C ° r iCe When 3 Pr ° CedUre f0r SOlVin9 3 su b P roblem already 

accnmnl/lh an r r lbrary ' by 3CC6SSing the description of what that procedure 

LhZn i 6 V f * Perf ° r0 rudimentary decompositions, and perform more 

substantial inferences when the user bypasses intermediate steps. Coupled with a 

detp°rmT C % H ann ° tati0n m ° dUle (SUCh 35 [Goldstein 1974]), SPADE-1 could 
specifi ti " many C3S6S) whether a 9 iven subprocedure satisfies its 


The introduction of formal problem descriptions provides a first 
improvement over SPADE-0; introducing pragmatic constraints at choice points in 
the grammar would provide a second. This leads to a more elaborate linguistic 
formalism which we briefly consider in the concluding section. 

While we plan to perform these extensions, from SPADE-0 to SPADE-1 and 
beyond SPADE -0 will still serve a useful role. The orammar based edited can 
support experiments on several important issues: (1) the adequacy of the 
Planning grammar; (2) the domain independence of the planning grammar; (3) the 
utility of the planning grammar in terms of structured programming 
considerations; (4) the pedagogical value of an articulate planning environment 

There is another dimension along which the theory as presented so far is 
incomplete. While the planning rules alone are sufficient to describe programs 

soiMt^ C> f ini * hed objects ’ the y do not capture the process of defining possible 
solutions, testing these solutions, and then debugging them. We need a theory of 

bugs, and of their diagnosis and repair, to supplement our theory of plans. This 
is the purpose of the next two sections. 
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j___ 

Figure 9. SPADE-1 Scena rio 


With a description of the problem, SPADE could be more helpful. 

i 

la. Tell me the name of your toplevel procedure’ 

lb. >WW 


2a. Would you like to define a model? 

2b. >WISHINGWELL 

3a. OK. WISHINGWELL model found in Model Library. 

Rule for WW-1 is: PLAN -> IDENTIFY | DECOMPOSE | REFORMULATE 
What now? 

3b. >ROOF POLE WELL 

4a ‘ corres P° nd to model parts. Are you pursuing a LINEAR 

DECOMPOSITION plan? 

4b. >YES 

i 

5a. The pending subgoals are: ROOF, POLE, WELL and the decisions regarding 

inclusion of preparatory steps (WW-5) for WW. What now’ 

5b. >ROOF 

6a. In the WW model, ROOF is described as a triangle. There is a TRIANGLE 

procedure in the answer library. Hence, an IDENTIFICATION plan may 
succeed. What now? 

6b. >IDENTIFY 

7a. The TRIANGLE procedure in the answer library satisfies the intrinsic 
description of ROOF. Would you like to use it’ 

7b. >YES 


8a. OK. The ROOF is complete. Your pending goals are POLE, WELL, and WW-5 
What now? 

8b. > 


9a. The first order goals for the parts are now complete. WW-5 (the choice 

0 praparator Y steps for WW) is complete. You have not expanded the 

definitions for the interface step, WW-6, nor for the cleanup step, WW- 
8. What now? 
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4. A Grammatical Theory of Debugging 

Bugs are so important that it is useful to classify them 
and give the classes names. In real world problem solving we 
often give names to important classes of bugs. In electrical 
engineering, for example, one class of bug is "instability." It 
may be manifest as "thermal runaway" or "spurious oscillation" 
in an amplifier. The underlying cause is "positive feedback," 
and there are several possible cures (patches) which may be 
applied: "negative feedback," or "isolation," for example. 

[Sussman, 1973, p. 170.] 

In earlier sections, we constructed a grammar of planning concepts and 

described programs as the terminal strings generated by this grammar. 

Unfortunately, problem solvers, whether human or machine, must often decide on a 

plan despite not only knowledge which is incomplete or uncertain, but also 

limitations on time and memory resources. The best of choices in such situations 

can turn out wrongly: debugging is then required. In this section, we follow 

Sussman's advice, developing a classification of bugs. Our goal in this 

classification scheme is to unify our approaches to planning and debugging by 

tracing the origin of bugs to various types of erroneous planning choices. In 

section five, we apply this perspective on possible planning errors to the design 

o a debugging assistant calledRAID to be incorporated into the SPADE 
environment. 


4.1. Types of Bugs 


Given our perspective on planning, debugging can be analyzed as the 

localization and repair of errors in applying the grammar rules during 

generation. Since our planning rules were constructed from operators for 

conjunction, for disjunction and for optionality, there arise three basic classes 
of error: 

(1) syntactic bugs in which the planning grammar is violated, 
such as when a required conjunct is missing. 

(2) semantic bugs in which the plan is syntactically well-formed 
but some semantic constraint arising from the particular 
problem is violated, such as when a syntactically optional 
constituent, needed because of the semantics of the 
particular problem, is missing. 

(3) pragmatic bugs in which an inappropriate selection from a 
set of mutually exclusive disjuncts is made. 
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This categorization is not complete: two other classes of bugs are 

circumlocutions" and "slips of the tongue." 13 The first class represents plans 

which are successful but inefficient. The second class refers to miscellaneous 

errors in execution including mis-typings, mis-spellings and incorrect 

programming language syntax that do not reflect basic conceptual mistakes in the 
plan. 


4.2. Syntactic Planning Bugs 

When a decision made during a problem solving session violates the 
planning grammar, the resultant bug is termed syntactic . M An example of a 
syntactic bug is failure to include an obligatory conjunct. To illustrate this, 
consider the following error. In the solution of a problem, one subgoal matches 
a previously solved problem. Hence, the problem solver incorporates a call to 
the appropriate subroutine into the solution. But it is common to forget to load 
the file containing the subroutine into the current workspace. Figure 10 
illustrates this difficulty: as before, the goal is to write a program that 
draws a wishingwell. The roof is a triangle, which corresponds to a previously 
defined subprocedure. A call to TRIANGLE is placed in the WW procedure, but WW 
is executed before the file containing TRIANGLE is loaded. 15 

In terms of our planning grammar, this is a syntactic bug. The WW 
procedure is ungrammatical. The appropriate rule describing this situation is: 

P4: DEFINED -> USE-CODE & GET-FILE 

but the file retrieval is missing. 

Thus, syntactic bugs are those in which a necessary conjunct of a 

planning rule is not present in the plan. (Syntactic bugs might also be caused 

by the presence of an illegal extra constituent, but this class of problems seems 

less common.) Normally one would not expect a machine problem solver to make 

this kind of error, given a correct planning theory and no heuristic limitations. 

However, resource limits on time or space might result in this performance 
Moreover, it is a common human error. 16 rormance. 

The basic technique for repairing a syntactic bug (once isolated) is to 

redo the culpable planning decision in such a way that the grammar is no longer 

violated. For the case of a missing but obligatory conjunct, this implies 

solving for the constituent in question, and incorporating that solution into the 

larger solution at the required point. For the WW example in particular, it 

means getting the TRIANGLE procedure from a file, and then reexecuting WW in’ the 
corrected environment. 
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Figure 10 

DEBUGGING A SYNTACTICALLY 



A NECESSARY CONJUNCT IS MISSING 


TO WW 

10 TRIANGLE 


USE 


END 


WW 


ID-PLAN 


GET 


??? TRIANGLE UNDEFINED ??? 


("GET" MISSING. UNGRAMMATICAL PLAN 
DEBUG BY COMPLETING PLAN.) 


GET TRIANGLE FILE 
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4.3. Semantic Planning Bugs 


v1 , . IT l bUgS differ fro ” atactic bugs in that no planning decision 
wh Jh I 5 the Underlying grammar; rather the usual case is that a constituent 

sem^t* 10 the 9rammar iS n0t P re sent, but is needed due to the 

semantics of the particular problem. This distinction can be understood more 

ear y y considering that syntax supplies broad constraints on the structure of 

solutions to all problems; semantics supplies additional constraints in terms of 

eatures of the particular problem at hand. Rules PI and P8 are typical rules in 
the grammar for which this kind of difficulty can arise: 


PI: SOLVE 
P8: SEQ 


-> PLAN + [DEBUG] 

-> [SETUP] + <MAINSTEP + [INTERFACE]/ + [CLEANUP]. 


__ U " ° 9 iS necessary if the Program produced during planning fails to 

complish its intended goals; otherwise, debugging is unnecessary. For a 

concrete example involving P8, let us return to the WW problem. Part of the 

Suooose that th Cati °H iS / hat . the Wishin9We11 be drawn ^ an upright position. 

POLE and th ufiT WhlCH th<3 0310 St ® PS ar ® executed ls to be: ROOF, 

, and then WELL. The subprocedure for the TRIANGLE expects the turtle to 

eg n a a vertex, oriented along the circumference. Therefore, an initial SETUP 

(syn actically optional) rotation is required to vertically orient the 

wishingweU as a whole. Furthermore, additional interface steps are required to 

establish the required relationship between the ROOF and the POLE, that the POLE 

connect to the ROOF by intersecting with the center of its bottom side. Figure 

nrJ ? PateS tHiS l0Cal 9eonetry ’ contrasting a semantically incomplete WW 
program to a corrected version. 

Since it is often an effective heuristic to design main steps before 
n er aces, one would not be surprised if a human programmer designed the 
subprocedures for the roof, pole and well, and then concatenated them, but forgot 
to indude these necessary interfaces. Moreover, even for a machine problem 
solver, there are situations in which it would be more efficient (and therefore 
rational) to determine the need, if any, for such interface steps via trial 
execution and debugging, than via thorough but resource-intensive initial 


In terms of the planning grammar, the overall plan for the WW is 
escribed as a sequential plan - that is, a sequence of main steps for the parts 
with optional interfaces. Given rule P8, the WW program illustrated by the 
previous figure is syntactically acceptable, but semantically incomplete. 

Semantic bugs can also occur when an optional constituent is present, but 
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DEBUGGING A SEMANTICALLY 



PLAN 


AN OPTIONAL CONJUNCT IS MISSING 


FOR EXAMPLE: 

"WIT MISSING xnu.xm. ou.ur, 
AND INTERFACE FOR POLE. 




TO WW 
10 WELL 
20 POLE 


MAINSTEP 
MAINSTEP 


-SEQ-PLAN 




\ Ha 


★USE 

OF MODEL PREDICATES TO 
COMPUTE MISSING STEPS. 


TO WW 

★5 WW-SETUP 
10 WELL — 


SETUP - 
MAINSTEP 


★15 WELL-POLE-INTER 
20 POLE 



. »\ 


MA INSTEP- 


FSEQ PLAN 


TO WW-SETUP 
10 RIGHT 90 
20 FORWARD 50 
30 RIGHT 90 


SEQ 


BODY OF 
SETUP STEP 



THE SEMANTICALLY CORRECTED PROCEDURE 
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semantically inappropriate. An example which we observed in a high school 
student was to always begin a procedure with the PENUP command, even when the 
first main step was to draw a visible vector. This resulted in either: (a) when 
the program was first run, the first vector would be missing, and then the PENUP 
would be deleted by a debugging edit; or (b) a PENDOWN command would be added to 
the procedure: inefficient but otherwise harmless extra steps. 

The general repair strategy for semantic bugs is to redo the culpable 

planning decision in such a way as to satisfy the violated semantic constraints. 

n particular the repair for a semantically incomplete plan is to solve for the 

missing conjuncts and incorporate them into the solution as a whole. For the 

wishingweH, this involves designing setup and interface steps, and then editing 
the WW superprocedure to employ them. 


4«4. Pragmatic Planning Bug s 

Some grammar rules describe alternative strategies to accomplish a given 
P an. Formally these appear as mutually exclusive disjuncts. Examples include: 

P2: PLAN -> IDENTIFY | DECOMPOSE | REFORMULATE 

P3 : IDENTIFY -> PRIMITIVE | DEFINED 

P6 : CONJUNCTION -> LINEAR | NONLINEAR 

P15: REPETITION -> ROUND | RECURSION 

Pragmatic bugs are those in which an incorrect disjunct is chosen. 


As an illustration, consider grammar rule P6 for conjunctive plans. It 
specifies two alternatives for accomplishing a set of subgoals: a linear and a 
nonlinear strategy. Now in this case, the formal roles played by the alternative 
disjuncts are syntactically indistinguishable with respect to the overall 
grammar. The pragmatic difference, which is not formalized here, is that a 
linear decomposition solves for the sub-problems independently while a nonlinear 
decomposition solves for some subgoals given knowledge of other subgoals. 


In general, linear plans are simpler to apply because of their 
independence assumption. However, pragmatic bugs arise when the planner is faced 
with a type of problem in which there are inherent interactions between the 
steps. An example of where linear problem solving is inadequate in the graphics 
world is the apparently simple task of drawing a square inside a triangle (figure 
12). Suppose a linear plan is pursued. This gives rise to two main steps (the 
square and the triangle), and an interface step. If the main steps are solved 
independently of one another (by means of SQUARE and TRIANGLE subprocedures) it 

i S * lk ® ly the figures Produced will be of the wrong size to permit'the 
desired INSIDE relation to hold. This violation cannot be corrected by altering 
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Figure 12 

DEBUGGING A PRAGMATICALLY INCORRECT PLAN 


AN INCORRECT DISJUNCT HAS BEEN SELECTED 


TO SQUARE-1NS IDE-TRIANGLE 
10 SQUARE 
20 TRIANGLE 
END 


LINEAR PLAN - 
SQUARE AND TRIANGLE 


o±<jrn 


INDEPENDENTLY. 


INTENDED PICTURE: 


ACTUAL PICTURE 




DEBUG BY CHANGING TO NON-LINEAR PLAN. 
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the order of composition; nor can it be repaired by modifying the interface. 

e ug is pragmatic, in that neither syntax nor semantics are violated, but the 

c o ce o the linear over the nonlinear disjunct nevertheless leads to an 
unsuccessful plan. 


A Pragmatic bug is repaired by redoing the culpable planning decision so 

as to satisfy the violated pragmatic constraint. (It may be that the problem 

olver was ignorant of the relevant constraint prior to solving the current 

problem This brings up the matter of skill acquisition which is deferred till 

the concluding soction.) In the SQUARE-WITHIN-TRIANGLE problem, violation of the 

predicate INSIDE is repaired by changing to a non-linear plan. The second main 

step to be solved must be designed in the context of a particular size decision 

ror the first main step. For example, the specification for TRIANGLE is changed 

to require that its side be larger than a constant which is determined by the 
side length of SQUARE. 


4.5. "Circumlocutions 11 (Inefficiency Bugs) 

A procedure which solves its specified problem, but in a roundabout 

“* n " e . r ’. is said t0 have a "circumlocution" or an inefficiency bug. Such 
e ficiencies can occur in plans where a non-optimal disjunct is chosen or an 
unnecessary (but harmless) optional constituent is included. Correcting 
ne ficiencies is the typical concern of compiler theory and we do not address it 
ere, except to make the point that the hierarchical annotation (or derivation) 
generated by the grammar is conceivably a useful description for a compiler to 


0 illustrate this, consider rational form violations, the subclass of 
nefficiencies due to local oddities in the code, such as sequential invocations 

. * . 9 V ® n . prim i tive - This class of inefficiencies has been extensively 

investigated m the literature on optimizing compilers. However, it is possible 

hat such a rational form violation is due to some serious omission in the 

U iS 9 warning that a bug may exist [Goldstein 1974]. 
Traditional compilers have no basis for a judgment, but access to the planning 
derivation of the program can often illuminate this issue. 

For example, one of the ways in which such an inefficiency bug can arise 

nlSiT* . U K Se ° f an " evolutionar y" Pl an Chiller 1976]. Although the grammar 
provided m this paper does not attempt to formalize this type of plan, basic 

olutionary plans are not complex. The programmer attempts to alter the code of 

a previous program to achieve the specifications of a new, but similar, problem. 

To illustrate such a situation, however, we must develop a somewhat elaborate 

example. Please reexamine figure 5. A wishingwell, initially viewed as 

involving three subproblems, has been reformulated so as to involve two main 
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steps, the TREE and the WELL. The TREE program is state transparent: it leaves 
the turtle in the same state in which it started, at the bottom of its TRUNK, 
(which serves as the POLE of WW). WW incorporates a nonlinearity for efficiency: 
the top side of the WELL is accomplished in two parts, to avoid retracing 
previous vectors. Suppose that the programmer needs a SQUARE subprocedure for 
use n another project. One strategy is to adapt WW by deleting the call to TREE 
( gure 13). After this deletion, though, the resulting SQUARE contains 
sequential calls to FORWARD: a rational form violation. The optimization is to 
combine these two invocations into a single call to the FORWARD primitive. 

.. Thus, a compiler could first check whether an evolutionary plan governs 

e inefficiency. If so, it could perform the optimization with some confidence, 
it not, it should notify the programmer of the oddity in the code. 


4.6. "Slips of the Tongue" (Execution Errors 



A final category of bugs is necessary when human programming protocols 
are to be analyzed. This class, "slips of the tongue," is a catch-all for 
typographical errors, confusions due to orthographic similarity, incorrect 
programming language syntax, noise on the computer line, and other failures to 
successfully type in a statement of code. They are often diagnosed by 
conventional computing environments, simply as a result of the code being 
unrecognizable. The plan is not affected. We include this class for 
completeness, so that our discussions may span the space of possible bugs. The 
planning grammar does not provide an explanation for the origins of these bugs. 19 


The general repair technique for slips of the tongue is to: (a) undo the 
side effects, if any, of the incorrect type-in; and (b) reexecute the type-in 
correctly in the restored environment. This could be captured by a rule such as: 

REPAIR -> [UNDO] + REDO 


A common error in debugging technique is to compound an initial "slip of the 
tongue error" by reexecuting, without undoing undesirable side effects. 20 


Having a classification of basic bug types does not solve the debugging 
problem: it is only a starting point. The next step is to develop a theory of 
diagnosis and repair, by which the underlying bug made manifest by an 
unsuccessful program run can be diagnosed, and then repair knowledge associated 

^ th n» h rl S bU9 . type can be a PP!ied to correct the program. Section five designs 
he RAID assistant that will monitor a programmer during the planning of a 

procedure and generate caveats regarding possible errors for aid in subsequent 
debugging. This monitoring will happen within the SPADE editing environment. 
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Figure 13 

DEBUGGING A CIRCUMLOCUTION OR INEFFICIENT PLAN 


TO WW 

5 RIGHT 90 
10 FORWARD 50 
20 TREE 
30 FORWARD 50 
A0 RIGHT 90 
50 FORWARD 100 
60 RIGHT 90 
70 FORWARD 100 
80 RIGHT 90 
90 FORWARD 100 


\ EVOLUTIONARY PLAN 




f 

I 


>TREE 




J 


SQUARE-1 


TO SQUARE-1 
5 RIGHT 90 
10 FORWARD 50 -j 
30 FORWARD 50J 
AO RIGHT 90 

i 


STARTS HERET 
ENDS HERE 


RATIONAL FORM VIOLATION 



\ CAVEAT DRIVEN DEBUGGING 

TO SQUARE-2 
5 RIGHT 90 
10 FORWARD 100 
AO RIGHT 90 
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Figure 14. A Surface Grammar For Debuggin' 


DEBUG -> <[DIAGNOSE] + [REPAIR]/ 
DIAGNOSE -> <ASK | TRACE | "error"/ 


TRACE 


-> [SELF-DOC*] + RUN* 


SELF-DOC -> ADD-PAUSE | ADD-PRINT | ADD-TRACE 


ASK 


-> "print definition" | "print value" |"print file"| 


REPAIR -> <RUN | EDIT | SOLVEV 


ADD-PAUSE -> ADD 


ADD-PRINT -> ADD 


ADD-TRACE -> ADD 


EDIT 


RUN 


ADD 


-> ADD | DELETE | CHANGE 

-> "run statement of code" + "response" + [DEBUG] 
-> "add statement of code" + "response" + [DEBUG] 


DELETE -> "delete statement of code" + "response" + [DEBUG] 

CHANGE -> "change statement of code" + "response" + [DEBUG] 


f t 
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FIGURE 15 - A TAXONOMY OF DEBUGGING TECHNIOUES 


DEBUG 
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PARSE—ADVISE (planning choices) 


•CODE 


-PRINTOUT 


■ADVISE (rational form violations) 
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DO 


REPAIR 


COMPLETE 


CORRECT 
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5_. The RAID Debugging Assistant 

Let us focus on one particular component of [general heuristic 
knowledge]: the art and techniques of ... debugging. The 
school experience is dominated by the normative attitude implied 
by "right answer vs. wrong answer". The mathematician's 
experience of mathematics is dominated by the purposeful- 
constructive attitude implied by the struggle to "make it work". 
He abandons an idea not because it happened to go wrong, but 
because he has understood that it is unfixable. Dwelling on 
what went wrong becomes a source of power rather than a piece of 

masochism (as it would appear to most fifth graders in 
traditional math classes). 

[Papert, 1973, p. 10] 


5.1. Diagnosis and Repair 


We have now developed a taxonomy of bug types — of what use is it? Its 
first use, we believe, is that it clarifies our understanding of debugging by 
identifying major categories of error. Secondly, it suggests how to design 
better debugging aids for the programmer and problem solver. In this section, we 
develop this position by designing the RAID component of the SPADE program 
editor. RAID is an acronym for RAtional Implementation of Debugging, stressing 
our belief that debugging is often a consequence of heuristically justifiable 
problem solving, not an embarrassment indicative of irrational or "sloppy" 

thinking. RAID is a tool designed to make debugging a source of power to the 
problem solver, as Papert suggests it can be. 

Let us consider further how the taxonomy clarifies our understanding of 
debugging. A programmer's approach to debugging is, naturally, colored by the 
diagnostic tools provided by the particular computer system. However, the 
facilities provided by a wide range of computing environments have much in 
common. These tools manifest what we term surface debugging techniques. They 
are based on examination of the code and snapshots of the computational process 
elicited by the code, both relatively superficial descriptions of the procedure 

as conceived by the programmer. Figure 14 shows a grammar which partially 
formalizes this surface debugging activity. 

Access to the problem description and -- most importantly -- the 

programmer's plan allows for a deeper analysis of debugging strategies. 

Figure 15 shows a taxonomy of these debugging strategies. Figure 16 shows how 

this taxonomy is transformed into what we term a deep debugging grammar, for 

contrast with the previous grammar. Notice that examination of the plan Dials an 
important role. 
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F igure 17. —RAID Advice for Syntactically Incomplete Plannlnn Bugs 


la. Which subgoal would you like to pursue? 

lb. >POLE 


2a. Rule for POLE-1 is: PLAN -> IDENTIFY j DECOMPOSE | REFORMULATE. 

What now? 

2b. MDENTIFY 

3a. Rule for POLE-2 is: IDENTIFY -> PRIMITIVE | DEFINED. 

What now? 

3b. >LATER. 

The LATER command causes further processing of this subgoal to be postponed. 

RAID, the debugging component, creates a caveat each time a LATER command occurs. 
The caveat records the fact that this part of the plan is syntactically 
incomplete at this point. 

4a. POLE-2 postponed. Your pending goal list contains the remaining subgoal 
WELL. Which goal would like to pursue? 

4b. >WELL 


5a. We have now completed the WELL subgoal. What now? 

5b. >RUN WISHINGWELL 

The caveat recorded earlier is a "demon,” triggered by premature execution of the 
procedure being designed. If this occurs, the function of the caveat is to 
remind the user of the syntactic incorrectness of the program. 

6a. 


6b. 

7a. You were solving POLE via an IDENTIFICATION plan. You postponed the 
decision (POLE-2) as to which answer library to use. 

The rule for POLE-2 is: IDENTIFY -> PRIMITIVE | DEFINED. 

What now? 


Running WISHINGWELL at this time results in the bug manifestation* 
UNDEFINED PROCEDURE: POLE. 

This is because WISHINGWELL is syntactically incomplete: it contains 

the pending subgoal POLE-2. The recommended repair technique is to 

complete the solution of the subgoal POLE-2. Would you like to work on 
POLE-2? 

>Yes. 
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Figure 16. A Deep Grammar For Debugqini 


DEBUG -> <[DIAGN0SE] + [REPAIR])’ 


DIAGNOSE -> <PARSE | CODE | MODEL | PROCESS)’ 


PROCESS -> ASK | TRACE | DO 


CODE -> PRINTOUT | "advise rational form violations" 


MODEL -> "advise model violations" 


PARSE 


-> "advise heuristic planning choices" 


REPAIR -) COMPLETE | CORRECT 


COMPLETE -> "solve for missing conjunct" 


CORRECT -> "choose alternative disjunct" 
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In the SPADE system, the end product of the interaction is not merely a 
program, but a program annotated by its associated plan derivation (please refer 
to figure 8 presented earlier). The reader has undoubtedly noted that far more 
interaction would be necessary with SPADE, than with an ordinary editor. 21 In 
return for this extra planning effort, there are several potential benefits. The 
first is that by knowing the plan, the RAID component of SPADE would generate 
caveats regarding possible bugs for aid in subsequent debugging. Since 
definition of the program generally occupies far less time than debugging, some 
additional effort in planning may well be worthwhile in terms of more efficient 
debugging. It is also possible that articulating the plan serves to improve a 
student's planning skills. 22 Finally, the plan as commentary should make the 
resulting code far more understandable to other programmers who, in large 
projects, may be expected to modify or debug the package. We have yet to 
consider "human-engineering" aspects in designing SPADE/RAID, nor have we begun 
to experiment with it. Here, our goal is only to describe those parts of the 
RAID debugging assistant that are predicated on our taxonomy of bug types. 


5.2. Aid In Diagnosing Syntactic Bugs 

SPADE provides the facility of being able to suspend the construction of 
a solution of one sub-problem in order to analyze other goals. This is useful, 
since occasionally insight into the solution of other goals is helpful for 
completing the current problem. SPADE provides bookkeeping facilities for this 
suspension. The goal can be resumed later. To illustrate this, we shall refer 
to figure 17. Line 3b shows the user choosing to postpone a goal. 

3a. Rule for POLE-2 is: IDENTIFY ->PRIMITIVE |DEFINED. 

What now? 

3b. >LATER. 

RAID, the debugging component, would create a caveat each time this 

happens. The caveat would record the fact that the plan is syntactically 

incomplete at this point. A caveat is a demon, which would triggered by 

premature execution of the procedure being designed. If this occurs, the 

function of the caveat would be to remind the user of the syntactic incorrectness 
of the program. 

5b. >RUN WISHINGWELL 

6a. Running WISHINGWELL at this time results in the bug manifestation: 

UNDEFINED PROCEDURE POLE. 

This is because WISHINGWELL is syntactically incomplete: it contains 

the pending subgoal POLE-2. The recommended repair technique is to 
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complete the solution of the subgoal POLE-2. Would you like to work on 
POLE-2? 


Line 6a in the figure illustrates this. 


5.3. Aid in Diagnosing Semantic Buns 

Whenever an optional constituent is rejected, RAID would create a caveat 

to the effect that the plan may be semantically incorrect at this point. When 

the program subsequently is executed and bugs occur, the programmer could request 

aid. This aid would include a description of which planning decisions are 

possible semantic errors. This sort of interaction with SPADE is illustrated by 
figure 18. 


Line lb shows the programmer choosing to dispense with an optional 
interface step. 


la. Is there an INTERFACE following WELL? 

lb. >N0 


When the program is subsequently tested at line 2b, the programmer is not 
satisfied with the results. 


4b. >ADVISE-PLAN 


5a. WELL may be semantically incomplete. Perhaps an INTERFACE is needed 
after WELL. Would you like to reconsider, and include such a step? 

RAID is then depicted pointing out that the decision to not include an optional 
interface may be the culprit (line 5a). 


5.4. Aid in Diagnosing Pragmatic Bugs 

Certain alternative planning methods have the relationship that one 

method is simpler but subject to failure in some cases, while the other is more 

complex but more powerful. Examples are LINEAR versus NONLINEAR plans and ROUND 

versus RECURSIVE plans. Whenever the user applies the simpler of one of these 

pairs, RAID creates a caveat to the effect that a commitment to a possibly 

incorrect plan has been made. This caveat serves the same purpose as those 

created above for possible semantic bugs. Upon subsequent execution, if the user 

is unhappy with the results, aid can be requested. The caveat then points out 
possible pragmatic errors. 
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F igure 18 _ . —RAID Advice For Semantically Incomplete Planning Bugs 


la. Is there an INTERFACE following WELL? 

lb. >NO 


Whenever an optional constituent is rejected, the RAID debugging component 

I creates a caveat to the effect that the plan may be semantically incomplete at 
this point. 

2a. We have now completed subgoal WELL. What now? 

2b. >RUN WISHINGWELL 

When the program subsequently is executed and bugs occur, the programmer can 
request aid. This aid includes a description of which planning decisions are 
possible semantic errors. In this case, the WW procedure produces a picture 
which does not satisfy the WISHINCWELL model. While SPADE-0 can aid in plan 
diagnosis, it cannot detect model violations without user input. (SPADE-1, 
however, would perform model diagnosis.) 

3a. OK. What now? 

3b. >DIAGNOSE 

4a. Rule is: 

DIAGNOSE -> ADVISE-PLAN | ADVISE-CODE | ADVISE-MODEL | ADVISE-PROCESS 
What now? 

4b. >ADVISE-PLAN 


5a. WELL may be semantically incomplete. Perhaps an INTERFACE is needed 
5b >y^ ter ^LL. Would you like to reconsider, and include such a step? 


6a. Solving for WELL-13 (INTERFACE after WELL). 
Rule is: SOLVE -> ... 
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Figure 19 illustrates this kind of interaction with SPADE. 
5b. >ADVISE-PLAN 


6a. In designing SQUARE-WITHIN-TRIANGLE-3, you opted for a LINEAR 
decomposition. It is possible that this problem involves some 
interaction between TRIANGLE and SQUARE. Do you wish to reconsider 
your previous decision, and try a NONLINEAR decomposition? 


Line 6a in the figure shows the RAID 
pragmatic planning bug. 


component alerting the user to a possible 


5.5. Assistance in Repair 


„„ ih . The , S i ySte " 1 c °“ ld d0 nore tha " alert the user to the problem, 
could also (a) return the user to the suspended goal, and (b) Inform the user, 

means of the grammar, of what alternative constituents are available. Line 7a 

figure 17 (presented earlier) Illustrates this repair assistance for the case 
a syntactic bug. 


It 

by 

of 

of 


7a. You were solving POLE via an IDENTIFICATION PLAN. You postponed the 
decision (POLE-2) as to which answer library to use. 

The rule for POLE-2 is: IDENTIFY -> PRIMITIVE | DEFINED. 


Suppose the user decides to undo a given planning decision, perhaps 
andonxng a very detailed plan which resulted from considerable effort, in favor 
of a new approach. It is possible that later the user may reconsider, and wish 
to reactivate the abandoned approach. It would be rather unfortunate if RAID had 
erased all records of its existence. In fact, it would not. In order to keep 

however bo * h * ct * y * f 1 " 1 hung alternative versions of each planning decision, 
however, the derivation tree representation ceases to be adequate. A more 

elaborate data structure is required; SPADE/RAID would use a chart for this 

r P Kav°iQ 73 - T K he i Cha ? 07 ?f a StrUCtUre Was introduced 1" computational linguistics 
3 ’ ^ Pla " 1973] t0 econora ^ally store a record of alternative well-formed 
substrings discovered during sentence parsing. Ve introduce the chart here for 

similar reasons. An example of such a chart applied to the planning context is 

shown in figure 20; figure 21 shows a user taking advantage of this capability. 

The chart data structure provides benefits which feed back into the 
planning assistant as well. For example, with the chart one can distinguish 
between using a copy of a previous subprocedure "in line," versus using the 
previous subprocedure as a "black box" which is invoked: 
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Fi gure 19. RAID Advice F or Pragmatically Incorrect Planning Bugs 


la. Rule for SQUARE-WITHIN-TRIANGLE-1 is: 

PLAN -> IDENTIFY | DECOMPOSE | REFORMULATE 
What now? 

lb. >CONJ 


2a. I have assumed DECOMPOSE -> CONJUNCTION. 

Rule for SQUARE-WITHIN-TRIANGLE-3 is: 

CONJUNCTION -> LINEAR | NON-LINEAR. 
What now? 

2b. >LINEAR 


sZn,11 ! Planning methods have the relationship that one method is 

simpler but subject to failure in some cases, while the other is more complex but 

7 E cL7n,Y fU , are LIUAR VerSUS mLINE M Plans and ROUND versus 
RECURSIVE pians. Whenever the user applies the simpler of one of these pairs. 

nlfr, rT * C T at t0 the effect that a ° possibly incorrect 

plait has been made. 


3a. Rule is 
3b. > 


4a. We have now completed SQUARE-WITHIN-TRIANGLE. What now? 
4b. >RUN SQUARE-WITHIN-TRIANGLE 


llpoj !«»«*««.t execution, if the user is unhuppp with the results. uU cun be 

SailAbE tlimru rnrlurU Pragmatic errors. Here, the 

SQUARE WITHIN-TRIANGLE procedure draws the picture "inside out." 




Rule is: 
DIAGNOSE -> 
What now? 
>ADVISE-PLAN 


ADVISE-PLAN | ADVISE-CODE | ADVISE-MODEL | ADVISE-PROCESS. 


6a. In designing SQUARE-WITHIN-TRIANGLE-3, you opted for a LINEAR 

decomposition. It is possible that this problem involves some 

interaction between TRIANGLE and SQUARE. Do you wish to reconsider 

your previous decision, and try a NONLINEAR decomposition? 

6b. >YES 

7a. What non-linear constraint(s) do you wish to add to the SQUARE? 






#• 
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Figure 21. Returning to a Previously Hung Plan 


la. Rule for WW-1 is: 

What now? 

lb. ^DECOMPOSE 


PLAN -> IDENTIFY | DECOMPOSE | REFORMULATE 


2a. What are your subgoals? 
2b. >ROOF POLE WELL 


3a. Rule for POLE-3 is: IDENTIFY -> PRIMITIVE | DEFINED 
What now? 

3b. >REDO WW-1 


Considerable planning effort has been invested in the current version of WW-1 

j! l l r 3y „ 7/ h0Uld be T able t0 record the state °f the work so far in case it is 
ver needed again. It might seem too costly, though, to save away multiple 

copies of the plan derivation every time a choice is redone... 


4a. Previous choice on WW-1 undone. 

Rule for WW-1 is: PLAN -> IDENTIFY | DECOMPOSE | REFORMULATE 
What now? 

4b. >REFORMULATE 




5a. What are your subgoals? 
5b. >TREE WELL 



6a. Rule is: SEQ -> [SETUP] + <MAINSTEP + [INTERFACE])* + [CLEANUP! 
What now? 

6b. >RED0 WW-1 

i 


At this point, the user has decided to return to the previous approach findin 
that the REFORMULATION has resulted in an even harder problem. SPADE’s chart 

representation for plan derivations in fact allows prior versions to be saved, 
without incurring overwhelming storage costs. 9 



7a. A previously hung version of WW-1 (WW-I:V1) exists, involving a 

DECOMPOSITION plan. Do you wish to reactivate it? 

7b. >YES 



i 


When WW-1:V1 was hung, your current goal was POLE-3. 
Rule for POLE-3 is: ... 
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P4 1 : DEFINED 


-> COPY-CODE|CALL-CODE & GET-FILE 


ch a „o« r “ le P4 ' 1,85 the VlrtUe that ona ca " whether /uture 

Mlved „ 8xls 't"3 eubprocedure should affect the procedure currently being 

olved. If the CALL-CODE disjunct Is chosen, the chart will contain only a 

aUo benefit th Shared SUbstructure; r “t<re improvements in the subprocedure will 

. ‘ C “ rrent [,roc " | ere. Conversely, future changes could introduce 

Pert “ rbations - Tb ts indicates how the insights gained from a 

ZT 1° Pr °a le " SOlVl " 9 Can Uad t0 r °™ellzing the origins of 
yet another commonly observed source of program bugs. 
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6. Conclusions 


6.1. Li mitations and Extensions 

Th ® ultimate version of SPADE ought to include a module for providing 

«ec J r 1 " 3 adVlC6 a " d fllUn3 ln la " ^ails of Jammy 

dmJLm H ° wever ' 8 context fr88 grammar, being inherently non- 
detenninietic, weald not suffice as the basis for a machine problem solver 

soluu™ ridTardly^rpMaLaV. 1 P °” ibl8 ^ a " d “ 8 " “sting for a 

sktll alS0 / theoretlcal deficiency. There ought to be a facility for 

JmJs to nreve'nt” : th prizing previous semantic or pragmatic planning 

,T«,v ■ recurrence on similar problems ln the future. Such a 

‘ was exhlblted by Sussman's [1973] HACKER program for example. But our 

ontext free grammar has no way of representing repair knowledge in such a way 
that semantic or pragmatic bugs are not repeated. 

fr(1(l „„ B ° th ° f these defici ^cies can be addressed by moving from the context 

f ° r Pla " nln3 k " 0 " 1Cd9e t0 a " ood-ootod transition 
network [Woods 1970]. Augmented transition networks generalize the context free 

T ° 566 th6 Way the A ™ ™ - a natural 
9 ralization of the grammar, first examine figure 22. Here we have an 

recursive lt 'transiti entat t ° n ° Z Plan " ing 9ramraar 35 a (non-augmented) 

i e transition network. The augmented transition network provides several 

generalizations: (1) registers can he provided to store the valujs of varuJIJ^ 

Ini O a«i S .r ^ a h S5 ° Clated " lth arCS t0 contro1 the order of transition:' 
" d , <3> °" S ca " »e associated with arcs to build structures during 

transitions. These generalizations were introduced in computational linguistics 

JJ" ltat M nS ° f , th ° CF ° repr8SBntatl “" that parallel those that we 
8 "!! , f the „ p “»lem solving realm. Figure 23 is the planning ATN based on 
2. Some (not all) of the registers, conditions, and actions (for storing and 

. lnr ° rmati0 " about th8 curr8nt sub-problem) are shown. Notice how 
greater efficiency can he achieved via technigues such as collapsing states - 

mg some information from the topological configuration to the registers 

(e.g the CONJUNCTION and SEQ+SET nodes). Figure 24 shows how arc predicate 

. , T t0 SCleCt th * approprl8t8 Plan type on the basis of features of the 
problem description. This approach (called PATH, for Planning ATH) is developed 

at length in [Goldstein a Miller 1976b], Here our goal Is only to show hoJ 

C ° Uld bS aC<,Uired ^ SPADE/RAID by fepnesenting planning knowledge 


consider again the SQUARE-WITHIN-TRIANGLE problem discussed in the RAID 
section. Recall that the underlying cause of the hug was treating the SQUARE^and 









FIGURE 22 - (NON AUGMENTED) RECURSIVE TRANSITION NETWORK FOR G2 




















FIGURE 23 - AN AUGMENTED TRANSITION NETWORK FOR PLANNING 
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FIGURE 24 

PATN'S DECOMPOSE NODE 
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constraint on th, * ^ lnd8!,8 " d8 "'- r " fact, a second order 

occurrences of th " ZeS "* S i “"’ 0S8d by tb8 INSIDE r «‘rtction. Future 
th! ?? 8rr ° r C0uld be 8reve " ted by adding a condition that tests for 

z: E prcdica,e to the a ~ — - — t f h. r 

... Specifically, this is done as follows: figure 25 shows that part of PATN 

that corresponds to the rule, 


P6: CONJUNCTION 


-> LINEAR | NONLINEAR. 


mhmi T d ur f AD Ult ar ° ° rdering causes the LINEAR Plan to be attempted first The 
ONLINEAR transition is allowed only if the NLC or NLD predicates recognize the 

is ta e ken aS and 0 th ainin9 K, a n ° nlinearity * Here ’ if «»IDE i* Present, the NLD loop 
is taken and the problem description modified to make the interaction explicit 

co„ S str e ai„ r t MTn'i^n 3 ^^ df Parts. Thus, a now arc 

orror f 1 a ' S8rVes t0 pr8V8 " t thls Particular pragmatic planning 

error from happening again. a 


6.2. Applications 


These ideas lend themselves to a variety of applications. 

three: automatic programming, automatic protocol analysis and 
programming. 


We consider 
structured 


As semantic and pragmatic capabilities are added to SPADE (reflected by 
increasing role of PATN in providing advice), the user would be consulted on 
progressively fewer planning decisions. The ultimate extension in this direction 

iouiH C0UrS 1 6 l SPADE t0 r6qUeSt n ° guidance at a H from the user. The user 
nrorl n problem description; SPADE would provide the solution 

dU r- ° ne " ovel aspect of approach to automatic programming is 

methodological: the SPADE series of systems provides an implementation strategy 
based on incremental simulation [Woods & Makhoul 1973]. X 

Automatic programming is an extension of SPADE in a direction in which 
the user is pushed toward the higher level planning decisions, whereas the system 

Hr™;/ tbe l0 T l8vel ‘"o^ 85 - Exploration in the opposite direction 
,w lit P t , bl ln th8 8xtr8 ” 8 this amounts to protocol analysis. Suppose 

that the problem solving of a SPADE user is running far ahead of the system the 

user may wish to type in code directly, rather than laboriously detailing the 
ntermediate steps of the plan. The system's job then becomes linking the low 
evel 8vent lnt0 a higher level planning structure. If every event typed by the 
user were at this code level, SPADE would superficially be serving as a 
conventional editing environment. The difference would lie in the assistance 
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r: 1 ”/ pazat« 'fTT d , ebu93lng - SPADE would havo a modulo (which 

1 PAZATII , for Protocol AnalZer Dosed on oa ATP) for inferring the user's 

ZTT a \* ll : eref0re be >ble t0 S “"° rt ”“ r **PT notion of debugging 

version of the SPADE T lml>liClt - Figure 26 ‘Hhstrate. how a hypothetical 

atiouit of interact aUSnM " ted by PAZA ™' c ° uld *‘»"tficantly reduce the 

^ToL e I re<, “ ired articolata «"> Planning knowledge os .sell os 

l£ok at' thT ai f f ^ y SySte "' [ " 1Uer * Goldste ‘" 1976dJ takes a more careful 
preLVnarJ design “* "** faCa ' a " d —« a 

The enti A fiba * ap P* ication is to prescribe improved programming methodology. 

»ructured%, en h ” enb ° diaS D1Jkatra ' s pb n pappb y of programming in a 
aeH a K °"' '"’ re0Ver ' 11 EO p resents a more detailed study of planning 

inJera tf 1,19 a teCb " i< " leS tba " ‘’ revi ‘ msl >' baa " attempted. It indicates how 
interactive editors can strongly encourage coherently structured articulate 

planning. The underlying theory provides an analysis of the nature and origin of 

- *fro» S i«?m iC h h , S T tS ° f bU9S Can be aV ° ided by irapr ° Ved design ’ and which 

choir-T jUStifiable heuristic choices. The occurrence of such uncertain 
... . . oweve, '» can be recorded, leading to bookkeeping and diagnostic 

bevn^rf 1 35 th ° Se Planned for RAID * Better debugging advice - going 

fand t C3Vea S ° r potentia l difficulties -- must await the incorporation of PATN 
(and to some extent PAZATN) into SPADE. 

hac . This report has presented a unified theory of planning and debugging 

environment ln9Ulstic analogy * The design of an interactive programming 
environment has also been described. The objectives for this programming 

thLrv^r^’ ? PADE ’ are that U serve ’ not only as a Practical application of the 
theory, but also as an experimental crucible for testing claims of the theory. 

We expect that experimentation with SPADE will yield the following kinds 

of information: (a) AI evidence regarding the heuristic adequacy of the planning 

taxonomy and grammar; (b) psychological evidence regarding the utility of the 

grammatical formalism as a modeling tool, for characterizing varying skill 

levels, in terms of which subsets of the grammar are used successfully and 

unsuccessfully; (c) computer science evidence regarding the efficacy of 

alternative documentation standards and design methodologies; and (d) 

pedagogical evidence regarding the value for a learner of programming in this 
type of articulate environment• 
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F igure 26. —A_Scenario Illu strating SPADE Augmented by PAZATN 

U ' T,f 1Vi ? f0r a UISHINCTEI -'-- Your pending subgoals are ROOF, 

POLE, WELL, and the interfaces. What now? 
lb. >SQUARE 

Here the user types in an event at level of the actual code. The proper 

SoiZV-: nr * fte .“ 4e f U SOlHn9 for MU using an IDENTIFICATION plan. 

QUARE is presumably in the user-defined answer library. 

2a. OK. I am assuming that WELL has been solved by IDENTIFYing it with the 
previously solved SQUARE procedure. What now? 

2b. >FORWARD 100 

Ill'll tl ' e “ Ser ha J typed in a ver y low-level event which requires careful 

lllthltZ>)° n ' c ° re ° nmber ° f VeCtor comand s *hich might be expected 
PO!F u a y F °f example ’ this could b e the interface between the WELL and the 

would beVaoVa lf theSQUARE used for the MLL is of size 100. then FORWARD 100 
vectaZhZt , s °’ J ° preparator y rotation would have been needed. The 

is alreadv intZ ° S,° f *** TRIMGLE /0f th * R00F ’ However > */ TRIANGLE 

solution Prnll anSW .l r y> an identi f icatiop »ould be expected, not a new 

• robobly, this vector accomplishes the next main step in PATN’s 

default solution order, POLE. However. PAZATN can employ a demon to postpone a 
final commitment until further evidence arrives . 

3a. OK. What now? 

3b. >TRIANGLE 

4a • 0K T Jj^! S R00F has been solved by IDENTIFICATION with the existing 

TRIANGLE. So the FORWARD 100 must be the POLE. Your only remaining 
su goals are the interfaces. Which interface would you like to solve? 


fllr Z noticin y bow few user type-ins have been required in this dialogue ~ 
almost eo»»rr in conventlonal code - yet the solution for the WISHINGWELL is 

rntZl Z V, n ° reover ' the 5 y* tem has inferred not only the code, but a 
her thorough description of the user's plan as well. This economy of 

nteroctton would be achievable by the combination of SPADE, PATN, and PAZATN 

enabling the user to focus on the few critical planning choices that more or less 
force the remainder of the solution. 
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7._Notes 


resoect frJf'th? S ° me ° Verlap ’ our objectives for SPADE differ in this 

C?eiteLnTo 7 n ,o° 7 f'u 65 th ° S6 WOrki " 9 t0 COnstruct Programing apprentices 
[Teitelman 1970,1974; Hewitt & Smith 1975; Rich & Shrobe 1975]. It is too earlv 

however, for a detailed comparison of either goals or methods. 

. , The v lrtues of the Logo graphics world [Papert 1971a,b; 1973] are: 

nn!^ 9 h? P f an environrnent in which Multiple problem descriptions are 

ran9 09 fr ° m Euclidean geometry to Cartesian geometry; (b) the 
possible programs range over a wide spectrum of complexity; and (c) there is 

ollZrl V 1973r mentati ° n °" hUIaan Perf ° rmanCe ln this area Goldstein 1973; 

nr h, 1’ Th6Se t3Sk d ° mainS arG natUral candidates for testing the generality 
vlrH.M T bl ° CkS W ° rld iS 3 benchnark AI domain which provides a 

wnMrt h T ? WhlCh t0 meaSUre thS progress of our approach. The set theory 

The r haS ts V r PtUeS ° f b ° th lntrinsic inter ®st and straightforward semantics. 
The creation of programs embodying concrete realizations of set theoretic 

the Hnm!? e 3 Programming task. Similar remarks are appropriate for 

° programming an elementary calculator, such as to perform routine 
statistical analyses. 

4. In [Goldstein & Miller 1976a] we presented a scenario for a 
programming tutor called Sherlock. One extension of the SPADE system presented 
Z\ *J°T i rd SU " h "K'f-tM'ti" AI based personal learning environments. At 

time ’ the SPADE st y le of interaction suggests a more structured 
. na ^ approach * Whet her the additional structure is desirable for some (or 
most) students is an empirical question to be addressed in future research. 

. 5 ‘ In C Miller & Goldstein 1976b] we presented a different version (Gl) of 

the planning taxonomy and grammar, in the context of parsing a student protocol. 

cu r :r nS T f ; r aba " d0ning that version in f av °r of the current one should be 
discussed. The earlier taxonomy was based on examining the directions from which 

to "domain 9UidanCe: l0 ° kin9 Upward to general Principles, downward 

° , SP T C heuristics ' forward to anticipated needs, and backwards to 

l ■ i-i S J S °^ Ved problems - The current taxonomy derives from examining the 

111™ f descriptlon of the curr ent problem. The former taxonomy emphasized the 

trllt * eXperimentation and use * of past problems; whereas the current one 

addre^pH 656 it \ 1S ’ S ° me ° f which (such as experimentation) remain to be 
ddressed. It remains true that decomposition techniques can vary along 

dimensions of domain specificity and generality. However, in some cases we found 

oraamatlr 6r a *° n ° m ^ t0 be Problematic. As we began to incorporate semantic and 
pragmatic constraints on the grammar (see [Goldstein & Miller 1976b]), it became 
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of domain 9 d h 'l" 1 ' malntai " a fornal distinction between certain examples 
assionino fn i a " e ™l““0"ary Plans. There is of course a trade-off in 

semantic or Tamat 8 *° the , syntactic rules ’ as °PP°s<»l to assigning it to 

claim that re C ° nStralnts on their application. In order to Justify a 

claim that the current version of the taxonomy is more parsimonious than the 

do in far?' ; 6 ;° Uld " 66d “ Carefuny lde " tlfy tha “n». af dot.. While wu 
this heliof’ 6 I’™ , the currcnt ver sion is more elegant, the grounds for 
upanr , remain intuitive. In subseguent research we intend to employ the 

tal„ V\ “ eXPCrl " CntaI vahlcU for contrasting alternative planning 
taxonomies and their corresponding grammars. 

to on h!‘ J he f ta ^ ement that there is a core set of planning techniques common 
t . 11 ma * ns is Justified by examining the formal basis for the taxonomy. On 

Staten? 7, r° blem descriptions are represented as predicate calculus 

statpllnt is clear that solution can proceed by: (l) identifying the 

statement as one for which a solution procedure is known to exist- (2) 

decomposing the problem into subproblems on the basis of the top level logistic 

nrnv^ t0r * reforraulating the Problem description such as by theorem 

P ing techniques. That is, domain independence of the core set of planning 

techniques holds, on o priori grounds, to the same extent that problems in the 
domain are descnbable using predicate calculus problem descriptions. 

° f ^ ou ” e this argument depends on the efficacy of the first order 
predicate calculus as a problem description language. While we are not prepared 

surrpT^ thU h , ere ’ U 15 Cl6ar th3t the calculus certainly has had some 
success in the past (e.g. in mathematics) and hence is an obvious candidate Its 

r^ 0 f Se ^.^ fiCienCieS ' SUCh as no "- dlrec ted inferencing. are discussed 

, * 6 n a / ler 1976b -^’ where we define a procedural problem solver 

organized around logical operators. It is also important to recognize that we 

not arguing for uniform (e.g., resolution-based) theorem prover style 
programming techniques. W yie 

n ° reover - extensions of the predicate calculus, such as higher-order 
calculi, do not obviate the need for basic problem solving techniques for dealing 
with conjunction, disjunction, negation, and quantification. 

. . 7 * Thi f View of plannin g is a simplification. It asserts that the 

p ism is analyzed m a top down fashion. Of course, the problem solver can 

having , ® Xplora “ on and experimentation; or can identify a subgoal without 

are not f ^ Uadarstanding of the 0Vera U Plan. The dynamics of exploration 
are not formalized by this grammar. 

8. Our use of a context free grammar for problem solving closely 
resembles D. Rumelhart's [1975] work on story grammars. It should be interesting 

LrfW U eX H te " t ° ur respective theories, designed to account for 

p f y r ry n / phenomena .' contlnue develop in parallel. Would 

be useful, for instance, to define a set of summarization rules (such as those 
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employed by Rumelhart) to describe the planning process? One possible set of 

noHL^nT 3 ^ 31100 rUl6S W ° Uld f ° CUS ° n the S0LVE nodes * oppressing printout for 

o er types. Conceivably, this could be useful in highlighting the 
subprocedure organization. xynugnsing me 


9. The rules of the grammar are written using the following syntax: 

disjunction: "a | b" is read as, "a or b"; 

ordered conjunction: "a + b" is read as, -a and b", 

where the order is significant; 

unordered conjunction: "a & b" is read as, "a and b\ 

where the order is insignificant; 

"[a]" is read as, "a is optional"; 

"<a>*" is read as, 

"a repeated 1 or more times"; 

lexical category: a lower case English phrase enclosed in 

quotation marks (e.g., "number") 
describes a lexical item which is not 
further expanded in the grammar. 


optionality: 

iteration: 


10. The & operator is used, because the GET and USE can occur in any 
order as long as they both precede execution of the procedure being defined. 

11. While the Mycroft system designed by Goldstein was potentially 
capa le of semantic annotation, it lacked a clear formalization of the range of 
possible planning choices a program designer could make, and a description of 

possible errors in terms of these design decisions. The grammar we present here 
is intended to address these limitations. 

12. The interactions presented here are hypothetical dialogues with a 

system which has not been implemented. Although a crude preliminary 

implementation (SPADE-00) has recently begun, it is currently lacking several 
essential features. 

rrmn * ° ne ? fiC 1 ien ^°^ SPADE '°° 13 that U haS not been interfaced with LLOGO 

" et ’ al - ! ® 74 3; hence U is not Possible to actually execute the 
resulting programs. Another deficiency is that the RAID features described in a 
later section have not yet been coded. 

The purpose of presenting hypothetical dialogues, rather than actual 
transcripts, Is to enable the reader to focus on the content, without being 
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Refil l h concerning the inadequacies of the implementation, 
invert t < aCCGSS t0 thS laboratory ' s timesharing system are nonetheless 
in WUh ° Ur trlal versions of SPADE as follows. After logging 
version :NSPADE wil l generally be a newer, highly experimental 

by :SPADE WiU ^ ° ld6r version ' in case of disastrous malfunctioning 
choice" s^y!^" 00 Simp ** fies tbe intera ction by employing a "menu" or "multiple 


WHAT WOULD YOU LIKE TO DO? 

=A -- IDENTIFY 

=B — DECOMPOSE 

=C — REFORMULATE 

>=a 


Certain operations, such as the LATER capability, are implemented as special 
escape commands," in order to reduce ambiguity and simplify parsing. For 

AYAinnl a • ** 


>later 

I DON'T UNDERSTAND: LATER. 
>@later 

POLE POSTPONED. 


Once started, the system is self-documenting, and is 

friendlier to use. Suggestions and bug messages may be 
mailer to SPADE0MIT-AI. 


gradually becoming 
sent via the system 


. The question arises as to whether the bug taxonomy is exhaustive when 
circumlocutions and slips of the tongue are also included. In a trivial sense 
e answer is "yes" because the latter class is open-ended by definition. In a 
deeper sense, the answer may also be "yes" in that no bugs need ever be assigned 

lit l Category which violate our intuitive requirement that the underlying plan 

nrnvp 6 ' This is a hypothesis we tentatively accept but cannot 

prove• 


. e ' V possible confusion, it should be stressed that our bug 
classification does not correspond to the usual terminology of programming lore. 

While there is a slight analogy, it may be misleading. That is, "syntactic 
Planning bugs" does not refer to the syntax of the programming language; it 
refers to the hierarchical structure of the process of constructing programs. 
Similar remarks are in order for semantic and pragmatic planning bugs. For 

” V “ y ; We . maj ; US ® the shorter phrases ’ "syntactic bug," to refer to a 
syntactic planning bug. For the most part, we are not concerned here with syntax 
errors (or semantic errors") in the usual sense. 
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if the L h f J6Ctl0n iS that this P articu lar bug could be eliminated 

Lrnl? f 9 environment were modified so as to automatically load 

ooint thJ th 1165 Wh6n needed> We cora P letel y ^ree. Indeed, it illustrates the 
point that the grammar illuminates the design of improved computing environments. 

pnv , ° ” ay alters the observation that, given any particular computing 

muirbe me a n dh'ered r t ain C °" Straints on ^he structure of programming plans 

of error violation of «»•*• constraints constitutes one type 


^ mnlv . * 0f ^ course, the issue arises as to whether the human problem solver is 

fn™ ™[ 9e i !! 9 ° f 9 kn0Wn rUl6 ' ° r iS unaware of th « rule in the proper 

l t0 3 S6t ° f difficult Problems in protocol analysis surrounding 
the hypothesizing of the grammar underlying a given individual's problem solving. 
This topic is pursued in [Miller & Goldstein 1976b,d]. 

. „ 17 - The occurrence two consecutive calls to a given primitive is odd 

® 3 t invoca tion, perhaps with altered input, will suffice. In Logo, two 

adjacent PENUP commands, or two adjacent FORWARD instructions would be considered 
rational form violations. 

18 ' This wishingwell program employs what Goldstein [1974] termed an 

insertion plan." The TREE shown here is inefficient in that it achieves state 

transparency via retracing the TRUNK. There is also a tradeoff in the WELL 

between modularity and efficiency. The use of the insertion plan to avoid 

retracing on the top side of the WELL results in less modular code. These points 

are no e on y to avoid misunderstanding — they have no bearing on the thrust of 
tne example, 

. . .. 19 -Viewing debugging from the vantage point of this taxonomy sheds some 

light on the issue of the pedagogical value of various kinds of bugs. Our 
current understanding of the first three (and to some extent the fourth) 
ategories of bugs suggests that encounters with such bugs may be instructive in 
teaching planning as well as debugging. However, "slips of the tongue" at best 
provide some exercise in bug localization. Hence, a "forgiving" system that 

The hJ 2 ? ^ P ® nalt r ieS f ° r $UCh l0W level bU9S is P ro bably pedagogically sound. 

< * " thlS philosophy is the Interlisp DUIFI (Do Vhat l Mean) 

facility [Teitelman 1970,1974]. (By contrast, our effort to make more of the 
plan explicit might be called SW/tf, i.e., Say What I Mean'.) 

. . , 20 • " e defl " e a co " text Tee gramnar for debugging, then this error In 

debugging technigue can be ciassifled. For example, if the rule of the debugging 
grammar for fixing slips of the tongue is: 


REPAIR 


-> [UNDO] + REDO 
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Sl "" “ ‘* " 0t al " ayS the error of 

side effects, ls ^oUc ^ 11 " 9 " * # C ° nfUSi °" tha “**»««• -f 

context tr,*"™ 1 " Vi !“, 0f dabu9s1 " 9 wo,lld be characterize planning as a 
t free grammar, while debugging is described as a transformational 

theorpM 4 1 t - hat . mapS deriva *i°n trees to derivation trees. This would be 

resolution 3 o/th^T^ ^ ^ P ° ssibility deserves further study. However, 
resolution of this issue goes beyond the current paper. 

which would he'," To bb ‘ ef * y introd " ce a “cdule we are designing called PAZATN 
which would help to alleviate this difficulty. PAZATN would he capable of 

porstnp programming protocols, inferring - from a combination of synthetic 
expectations and analytic evidence - which plans had been used. 

bv d„i„„ 2 L\I U “ al hypothesis ° f thB b °3° project is that children learn 
the smF di, ' ° Ut ' Dh ° t the “ d °' 0na of our PerPcses in implementing 

merits of spa? * e f bl ° ra tbls " y P° the sis by experimenting with the relative 
. E ersus the traditional Logo programming environment. In SPADE 

bUnnino d l H artlCUlata ' «*■ "elps students to ZTtlr 

seen Our T" 9 concepts "° re 9ul '*l y ” °r hinders them - remains to be 

W -firth? 9 :: “? I* tha : deSPite tba extra demanded, students 

he " learn,„ n fticulate about their problem solving a significant 

.I " 3 ’ “ DaaSUrad by aa ablllty tp soly » "seder problems more 
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